Computing label-switched data communication paths

ABSTRACT

Methods, systems, and computer readable media for computing label-switched data communication paths are disclosed. An example method includes receiving, by a path computation element (PCE) implemented on at least one processor, synchronization status information for routing nodes in a label-switched network. The method includes receiving, by the PCE, a request for a label-switched path (LSP) from a client. The method includes determining, by the PCE, a responsive LSP based at least in part on the synchronization status information. The method includes sending, by the PCE, an explicit route object (ERO) for the responsive LSP to the client.

PRIORITY CLAIM

This application is a divisional of U.S. patent application Ser. No.15/713,558, filed Sep. 22, 2017; the disclosure of which is incorporatedherein by reference in its entirety.

TECHNICAL FIELD

The subject matter described in this specification relates generally tocomputing label-switched data communication paths, e.g., throughsynchronized routing nodes in a segment routed (SR) multiprotocol labelswitching (MPLS) label-switched network, and to validatinglabel-switched data communication paths.

BACKGROUND

A path computation element (PCE) is an entity, often used within anMultiprotocol Label Switching (MPLS) environment, that is capable ofcomputing a suitable network path for transmitting data between a sourceand destination by applying computational constraints. Routers in alabel-switched network each typically have an internal clock, which mayexperience drift over time. Routers with clocks out of synchronizationmay present various issues with control plane functioning. ConventionalPCE architectures do not consider synchronization between routers whilecomputing label-switched paths (LSPs). Such LSPs are prone to provideincorrect and often misleading ping statistics and may be morevulnerable from sudden outages leading to disruption of MPLS trafficengineering (TE) services.

Accordingly, a need exists for improved methods, systems, and computerreadable media for computing label-switched data communication paths toaddress synchronization and to validating label-switched datacommunication paths.

SUMMARY

Methods, systems, and computer readable media for computinglabel-switched data communication paths among synchronized nodes aredisclosed. An example method includes receiving, by a path computationelement (PCE) implemented on at least one processor, synchronizationstatus information for routing nodes in a label-switched network. Thelabel-switched network may be a segment routed (SR) multiprotocol labelswitching (MPLS) network. The method includes receiving, by the PCE, arequest for a label-switched path (LSP) from a client. The methodincludes determining, by the PCE, a responsive LSP based at least inpart on the synchronization status information. The method includessending, by the PCE, an explicit route object (ERO) for the responsiveLSP to the client.

The features described in this specification may be implemented usingany appropriate combination of computing components, for example,hardware, software, and firmware. The terms “function” “node” or“module” refer to hardware, which may also include software and/orfirmware components, for implementing the feature being described. Insome examples, the features described in this specification may beimplemented using a computer readable medium storing computer executableinstructions that when executed by at least one processor of a computercontrol the computer to perform operations. Examples of appropriatecomputer readable media include non-transitory computer-readable media,such as disk memory devices, chip memory devices, programmable logicdevices, and application specific integrated circuits. A computerreadable medium may be located on a single device or computing platformor may be distributed across multiple devices or computing platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example network for computinglabel-switched data communication paths and validating label-switcheddata communication paths;

FIG. 2 illustrates an example computer system implementing the PCE ofFIG. 1;

FIG. 3 illustrates an example computer system implementing the PCC ofFIG. 1;

FIG. 4 is a message diagram illustrating an example message exchange forcomputing label-switched data communication paths;

FIG. 5 is a message diagram illustrating an example message exchange forcomputing label-switched data communication paths;

FIG. 6 is a message diagram illustrating an example message exchange forvalidating label-switched data communication paths;

FIG. 7 is a flow diagram of an example method for computinglabel-switched data communication paths; and

FIG. 8 is a flow diagram of an example method for computinglabel-switched data communication paths.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example network 100 for computinglabel-switched data communication paths, e.g., through synchronizedrouting nodes, and to validating label-switched data communicationpaths. Network 100 includes a path computation element (PCE) 102, andpath computation client (PCC) 104, and a label-switched path (LSP) endpoint 106. Network 100 can be any appropriate type of label-switchednetwork, e.g., a segment routed (SR) multiprotocol label switching(MPLS) label-switched network.

MPLS networks may be used in high-bandwidth telecommunications networksand other appropriate networks. In general, MPLS networks route databetween routing nodes in the network based on path labels instead ofnetwork addresses. A routing node is typically a hardware device or anumber of devices configured for receiving and routing network messages;for example, a routing node can be a label switch router, a label edgerouter, or a provider router.

Using path labels can be useful, e.g., to avoid complex lookups in arouting table. The path labels typically identify paths, i.e., virtuallinks, between distant routing nodes. MPLS can encapsulate packets ofvarious network protocols, and MPLS generally supports a variety ofaccess technologies. MPLS typically works in conjunction with theinternet protocol (IP) and its routing protocols, e.g., interior gatewayprotocol (IGP).

PCE 102 is configured for computing a suitable network path fortransmitting data between a source and destination by applyingcomputational constraints. PCE 102 can be implemented as an externalserver application or, alternatively, can be integrated within/coupledto a network component such as the headend router. PCE 102 includes apath determiner such as a constrained shortest path first (CSPF) module108.

PCE 102 builds core network topology and Traffic Engineering Database(TED) 110 based on Interior Gateway Protocol (IGP) TE extensions. PCE102 gathers network resource information like topology, bandwidth, linkcosts, existing LSPs and the like. This information can be collected viapeering with IGPs (OSPF, IS-IS) or BGP-LS.

In operation, PCE 102 operates as an active, stateful PCE to modify oneor more LSP attributes, such as a bandwidth, an explicit route object(ERO) to modify the path, and a priority (setup and hold). EROs limitLSP routing to a specified list of routing nodes. EROs can specify,e.g., loose hops and strict hops. PCE 102 can use a path computationelement protocol (PCEP) to communicate these new LSP attributes from PCE102 to PCC 104, after which PCC 104 re-signals the LSP in the specifiedpath.

In the example illustrated in FIG. 1, a transmission control protocol(TCP)-based PCEP session connects PCC 104 to PCE 102. PCC 104 initiates,using an LSP manager 112, the PCEP session and stays connected to PCE102 for the duration of the PCEP session. During the PCEP session, PCC104 requests LSP parameters from PCE 102.

On receiving one or more LSP parameters from PCE 102, PCC 104 re-signalsthe TE LSP. When the PCEP session is terminated, the underlying TCPconnection is closed immediately. PCC 104 may attempt to re-establishthe PCEP session.

Standard MPLS Operations, Administration, and Maintenance (OAM)techniques like LSP Ping/Traceroute use network time protocol (NTP)timestamp comparisons and do not generally use hardware timestamps. Someconventional PCEs compute MPLS LSPs based just on TE parameters.Examples of TE parameters may include, link bandwidth associated with ahop, lowest number of hops between source and destination, and the like.

Typically, forwarding plane issues are detected outside of PCE 102through an MPLS OAM subsystem. So even when PCE 102 is able to calculatea LSP with a proper TE constraint (e.g. high bandwidth), such LSP willnot be ready for MPLS OAM unless LSP end routers are synchronizedproperly with an NTP master (since an LSP ping uses NTP timestamp inMPLS echo request and reply).

Moreover, one common issue for IGPs is MD5 authentication, e.g., atinterface level as well as for route updates and performingauthentication through hitless rollover using key chain. Because ofclock skew amongst routers in the ERO, rollover may be impactedresulting in both router level and interface level authentication tofail. Authentication failure can impact router operation.

Routers with their clocks out of synchronization with a common stratumand also among themselves may pose various issues with control planefunctioning. Each routers has an internal clock which may experiencedrift over a period. So with differing clocks, routers do not have acoherent treatment on remaining lifetime of a LSP which plays a key rolein LSP purge function.

Some conventional IGP protocols like open shortest path first (OSPF) andintermediate systems to intermediate system (IS-IS) do this in aslightly different manner. While OSPF only allows only self-originatedlink state advertisement (LSA) to be purged, IS-IS allows in certaincases even non-self-originated purging. So the first router that detectsthat a LSP's lifetime has gone to zero then initiates a network-widepurge of that expired LSP. Lack of clock synchronization amongparticipating routers make the decision random and increases controlplane load.

In light of these issues related to synchronization among routers in anMPLS networking environment, PCE 102 can be configured to compute an LSPthat takes into consideration the degree of synchronization that existsbetween the routing nodes that comprise a chosen path.

FIG. 2 illustrates an example computer system 200 implementing the PCE102 of FIG. 1. Computer system 200 includes at least one processor 202and memory 204 (e.g., random access memory) storing executableinstructions for the processor. Computer system 200 includes the PCE 102which is implemented using processors 202 and memory 204.

While the high level function of a PCE is defined, the particularalgorithm(s) used to compute a path through the network are notmandated. Some standards documents (e.g., the base specification RFC5440 that introduces PCEP and other accompanying specifications fromIETF) do not attempt to standardize path computation algorithms.

PCE 102 may be configured for extending path computation elementprotocol (PCEP) to announce synchronized path computation ability forthe label-switched network. PCE 102 may also be configured for extendingthe PCEP to support receiving client requests for synchronized pathcomputation. For example, PCE 102 may implement a “Synchronization awarecomputation capability” type-length-value (TLV) as part of PCEP OPENobject to announce support for the feature in an open message whilesetting up a PCEP session.

As illustrated in the example of FIG. 2, PCE 102 includes asynchronization status collector 206, a path determiner 208, and asynchronization-aware path determiner 210. Synchronization statuscollector 206 is configured for receiving synchronization statusinformation for routing nodes in a label-switched network. Pathdeterminer 208 is configured for determining LSPs using conventional TEparameters. Synchronization-aware path determiner 210 is configured fordetermining LSPs based at least in part on the synchronization statusinformation collected by synchronization status collector 206.

Some conventional routers use NTP to synchronize their system clockswith an external time source (e.g. a reference Clock, or with a globalpositioning system (GPS)). NTP is a hierarchical protocol and is dividedinto stratum which define the distance from the reference clock.Receiving synchronization status information can include receivingnetwork time protocol (NTP) stratum information for each routing node.

A reference clock source that relays UTC (Coordinated Universal Time)time and has little or no delay is known as a stratum-0 device.Stratum-0 servers generally are not used on the network; instead, theyare directly connected to computers which then operate as primary timeservers. A primary server that receives a time signal from a stratum 0device either through the GPS network or national time and frequencytransmission is known as a stratum-1 device.

On a network a stratum 1 time server supplies the time to other deviceson the network which are known as stratum-2 devices. These also can beused as a time source and equipment that connects to a stratum-2 deviceto receive it become stratum-3 and so on. NTP can handle up to 16different stratum levels, although the lower down the hierarchy you gothe less accurate the devices become and stratum 16 indicates the deviceis unsynchronized.

A router within an MPLS networking environment connects to an NTP timeserver, where the time server is associated with a given NTP stratum.The router's OA&M subsystem maintains synchronization statusinformation, which includes information that identifies the stratum ofthe time server to which it is connected. Synchronization statuscollector 206 can collect the synchronization information using anyappropriate technique and may store the synchronization information,e.g., in a relational database indexed by router identifiers.

For instance, in some examples, synchronization status collector 206 isconfigured to communicate with or otherwise has access to thesynchronization status information associated with the router. Forexample, synchronization status collector 206 may use simple networkmanagement protocol (SNMP) or another communication protocol to querythe router and obtain its synchronization status information including,but not limited to, its NTP stratum.

In some other examples, synchronization status collector 206 may bemanually provisioned with synchronization status information associatedwith the router. In some other examples, the router may broadcast itssynchronization status information to synchronization status collector206.

Alternatively, a monitoring system may monitor NTP-related messagingwithin the network and determine the router's synchronization status(e.g., to which NTP time server the router is connected and theassociated stratum of that time server). The monitoring system is thenadapted to communicate or share this synchronization status informationwith synchronization status collector 206.

The availability of router synchronization status information across therange of routers associated with potential label switched pathsrepresenting ERO hops enables PCE 102 to apply more restrictive and, inmany cases, considerably more useful constraints (e.g., avoiding routerswith NTP status stratum 16, where stratum 16 indicates that the routeris disconnected from the NTP synchronization network).Synchronization-aware path determiner 210 can effectively avoidconstructing a path which includes routers that are furthest away froman authoritative time source, since being furthest away from theauthoritative time source generally indicates a larger synchronizationerror.

As such, PCE 102 is configured for computing a label switched path basednot only on conventional TE parameters (e.g., bandwidth, etc.), but alsoon the degree or precision of synchronization between routers comprisinga given path. PCE 102 can therefor preferentially select a highsynchronization quality path, in situations where it is requested (e.g.,for environments employing hitless rollover using key chain, or otherauthorization techniques.)

In some examples, PCE 102 uses both path determiner 208 andsynchronization-aware path determiner 210 to compute an LSP for a givensource and destination. Path determiner 208 computes a initial pathbetween the source and the destination without considering thesynchronization status information. Then, synchronization-aware pathdeterminer 210 prunes the initial LSP based on the synchronizationstatus information to remove from the initial LSP one or more routingnodes, e.g., routing nodes each having a degree of synchronizationfalling below a threshold degree of synchronization. For example,pruning the initial LSP can include pruning ERO nodes with NTPstatus<stratum×(e.g., <stratum 16). PCE 102 can determine back-up pathsin the same manner.

FIG. 3 illustrates an example computer system 300 implementing the PCC104 of FIG. 1. Computer system 300 includes at least one processor 302and memory 304 (e.g., random access memory) storing executableinstructions for the processor. Computer system 300 includes the PCC 104which is implemented using processors 302 and memory 304.

PCC 104 includes a multiprotocol label switching (MPLS) operations,administration, and maintenance (OAM) emulator 306. MPLS OAM emulator306 is implemented on processors 302 and memory 304. MPLS OAM emulator306 is configured for emulating an MPLS element in a label-switchednetwork. PCC 104 also includes a test traffic generator 308 configuredfor generating test packets for testing LSPs. PCC 104, while requestingan LSP between source and destination nodes, may implement a METRIC type“SYNC” (along with existing metric types such as TE, IGP, Hop Count) toinform a synchronization-aware PCE that PCC 104 is requesting asynchronization-aware path computation (e.g. exclude NTP stratum 16nodes).

In operation, MPLS OAM emulator 306 receives, from a path computationelement (PCE) for the label-switching network, a segment routing (SR)explicit route object (ERO) for a label-switched path (LSP) determinedby the PCE using synchronization status information for a plurality ofrouting nodes in the label-switched network. MPLS OAM emulator 306 sendsan MPLS echo request to downstream routing nodes specified by the SRERO. MPLS OAM emulator 306 receives a respective MPLS echo reply fromeach of the downstream routing nodes. MPLS OAM emulator 306 validatesthe LSP using the MPLS echo replies and, in response to validating theLSP, transitioning the LSP state from down to up.

FIG. 4 is a message diagram illustrating an example message exchange 400for computing label-switched data communication paths. During messageexchange 400, a PCE 402 having a router synchronization statusinformation database 404 exchanges messages with an OAM node 406 that isin communication with at least one router 408 (e.g., a PCC or a transithop node).

PCE 402 receives a message 410 from a PCC with a request to compute aLSP for a given source and destination. PCE 402 sends a message 412 toOAM sub-system 406 of transit router 408 with a request forsynchronization status information for the router 408. OAM node 406sends a message 414 with the synchronization status information, and PCE402 stores the synchronization status information in database 404. PCE402 then uses 416 the synchronization status information, andsynchronization status information for other routers collected in asimilar manner being considered for the LSP which is stored in database404, as a factor when computing the LSP responsive to message 410. PCE402 sends a message 418 with an ERO for the responsive LSP to theclient.

FIG. 5 is a message diagram illustrating an example message exchange 500for computing label-switched data communication paths. During messageexchange 500, a PCE 502 having a router synchronization statusinformation database 504 exchanges messages with a monitoring probe 510that is monitoring messages between an OAM sub-system 506 of transitrouter 508 (representing the part of ERO determined by path determinerwith considering synchronization information) and an NTP source 512.

PCE 502 receives a message 514 from a PCC with a request to compute aLSP for a given source and destination. Monitoring probe 510 monitors amessage 516 from NTP source 512 to OAM sub-system 506 and determinessynchronization status information for router 508 based on message 516.Monitoring probe 510 sends a message 518 to PCE 502 with thesynchronization status information, and PCE 502 stores thesynchronization status information in database 504. PCE 502 then uses520 the synchronization status information, and synchronization statusinformation for other routers collected in a similar manner beingconsidered for the LSP which is stored in database 504, as a factor whencomputing the LSP response to message 514. PCE 502 sends a message 522with an ERO for the responsive LSP to the client.

FIG. 6 is a message diagram illustrating an example message exchange 600for validating label-switched data communication paths. During messageexchange 600, messages are exchanged between a PCE 602, a PCC 604, and asegment routed (SR) ERO topology 606 including at least routing nodes608, 610, 612, and 614.

PCE 602 sends a message 616 to PCC 604 with an SR ERO specifying routingnodes 608, 610, 612, and 614. PCE 602 determined the SR ERO usingsynchronization status information for routing nodes 608, 610, 612, and614, so that sender and receiver timestamps in an MPLS echo request andreply are guaranteed to be correct or accurate to at least a thresholdlevel of accuracy.

PCC 604 sends an MPLS echo request 618 to routing nodes 608, 610, 612,and 614. PCC 604 receives MPLS echo replies 620, 622, 624, and 626 fromeach of routing nodes 608, 610, 612, and 614. PCC 604 interprets MPLSecho replies 620, 622, 624, and 626 to validate the LSP specified by theSR ERO from PCE 602. In response to validating the LSP, PCC 604transitions the LSP state from down to up and begins transmittingmessages 628 with test traffic, e.g., layer 2-layer 3 (L2-L3) testtraffic.

FIG. 7 is a flow diagram of an example method 700 for computinglabel-switched data communication paths. Method 700 may be performed bythe PCE 102 of FIGS. 1 and 2.

Method 700 includes receiving 702 synchronization status information forrouting nodes in a label-switched network. Receiving synchronizationstatus information can include receiving network time protocol (NTP)stratum information for each routing node. Receiving synchronizationstatus information can include requesting the synchronization statusinformation from an operations, administration, and maintenance (OAM)subsystem of the label-switched network.

In some examples, receiving synchronization status information includesreceiving the synchronization status information from a monitoringsystem monitoring synchronization messaging by the routing nodes in thelabel-switched network. In some other examples, receivingsynchronization status information includes querying each of the routingnodes or receiving broadcast messages from each of the routing nodes.

Method 700 includes receiving 704 a request for a label-switched path(LSP) from a client. Method 700 includes determining 706 a responsiveLSP based at least in part on the synchronization status information.Method 700 includes sending 708 an explicit route object (ERO) for theresponsive LSP to the client.

Determining 706 the responsive LSP can include determining an initialLSP based on one or more traffic engineering parameters. Method 700 canthen include pruning the initial LSP based on the synchronization statusinformation to remove from the initial LSP one or more routing nodeseach having a respective degree of synchronization below a thresholddegree of synchronization.

In some examples, the routing nodes in the label-switched network areconfigured to communicate using a routing protocol specifying asynchronization-sensitive authentication. For instance, in someexamples, the routing nodes in the label-switched network are configuredto communicate using an intermediate system to intermediate system(IS-IS) protocol and to authenticate using hitless authentication keyrollover.

IS-IS allows for the configuration of a password for a specified link,an area, or a domain. Routers that want to become neighbors exchange thesame password for their configured level of authentication. A router notin possession of the appropriate password is prohibited fromparticipating in the corresponding function (that is, it may notinitialize a link, be a member of an area, or be a member of a Level 2domain, respectively.)

IS-IS protocol exchanges can be authenticated to guarantee that onlytrusted routing devices participate in routing. By default,authentication is disabled. The authentication algorithm creates anencoded checksum that is included in the transmitted packet. Thereceiving routing device uses an authentication key (password) to verifythe packet's checksum.

If authentication is configured for all peers, each peer in that groupinherits the group's authentication. Authentication keys can be updatedwithout resetting any IS-IS neighbor sessions. This is referred to ashitless authentication key rollover. Hitless authentication key rolloveruses authentication keychains, which include authentication keys thatare being updated. The keychain includes multiple keys. Each key in thekeychain has a unique start time. At the next key's start time, arollover occurs from the current key to the next key, and the next keybecomes the current key.

The algorithm through which authentication is established can beconfigured, e.g., to use MD5 or secure hash algorithm (SHA)authentication. A keychain is associated with the authenticationalgorithm and an IS-IS neighboring session. Each key contains anidentifier and a secret password.

The sending peer chooses the active key based on the system time and thestart times of the keys in the keychain. The receiving peer determinesthe key with which it authenticates based on the incoming keyidentifier. Due to the use of timing information, hitless authenticationkey rollover is synchronization-sensitive.

FIG. 8 is a flow diagram of an example method 800 for using computedlabel-switched data communication paths at PCC. Method 800 may beperformed by the PCC 104 of FIGS. 1 and 3.

Method 800 includes receiving 802, from a path computation element (PCE)for the label-switching network, a segment routing (SR) explicit routeobject (ERO) for a label-switched path (LSP) determined by the PCE usingsynchronization status information for a plurality of routing nodes inthe label-switched network.

Method 800 includes sending 804 an MPLS echo request to downstreamrouting nodes specified by the SR ERO. Sending 804 the MPLS echo requestto the downstream routing nodes can include sending the MPLS echorequest with a target forwarding equivalence class (FEC) stacktype-length-value (TLV) for validating the LSP.

Method 800 includes receiving 806 a respective MPLS echo reply from eachof the downstream routing nodes. Method 800 includes validating 808 theLSP using the MPLS echo replies and, in response to validating the LSP,transitioning the LSP state from down to up. In some examples, method800 includes informing a test traffic generator to inject test packetsinto the LSP in response to validating the LSP.

Although specific examples and features have been described above, theseexamples and features are not intended to limit the scope of the presentdisclosure, even where only a single example is described with respectto a particular feature. Examples of features provided in the disclosureare intended to be illustrative rather than restrictive unless statedotherwise. The above description is intended to cover such alternatives,modifications, and equivalents as would be apparent to a person skilledin the art having the benefit of this disclosure.

The scope of the present disclosure includes any feature or combinationof features disclosed in this specification (either explicitly orimplicitly), or any generalization of features disclosed, whether or notsuch features or generalizations mitigate any or all of the problemsdescribed in this specification. Accordingly, new claims may beformulated during prosecution of this application (or an applicationclaiming priority to this application) to any such combination offeatures. In particular, with reference to the appended claims, featuresfrom dependent claims may be combined with those of the independentclaims and features from respective independent claims may be combinedin any appropriate manner and not merely in the specific combinationsenumerated in the appended claims.

What is claimed is:
 1. A system for validating label-switched datacommunication paths, the system comprising: at least one processor; anda multiprotocol label switching (MPLS) operations, administration, andmaintenance (OAM) emulator, implemented on the at least one processor,and configured for emulating an MPLS element in a label-switched networkand for: receiving, from a path computation element (PCE) for thelabel-switching network, a segment routing (SR) explicit route object(ERG) for a label-switched path (LSP) determined by the PCE usingsynchronization status information for a plurality of routing nodes inthe label-switched network; sending an MPLS echo request to a pluralityof downstream routing nodes specified by the SR ERG; receiving arespective MPLS echo reply from each of the downstream routing nodes;and validating the LSP using the MPLS echo replies using sent andreceived timestamps and, in response to validating the LSP,transitioning the LSP state from down to up; wherein sending an MPLSecho request to the downstream routing nodes comprises sending the MPLSecho request with a target forwarding equivalence class (FEC) stacktype-length-value (TLV) for validating the LSP.
 2. The system of claim 1comprising a test traffic generator configured for generating testpackets for testing the LSP, wherein the MPLS OAM emulator is configuredfor informing the test traffic generator to inject the test packets intothe LSP in response to validating the LSP.
 3. A method for validatinglabel-switched data communication paths, the method comprising: at amultiprotocol label switching (MPLS) operations, administration, andmaintenance (GAM) emulator, implemented on the at least one processor,and configured for emulating an MPLS element in a label-switchednetwork: receiving, from a path computation element (PCE) for thelabel-switching network, a segment routing (SR) explicit route object(ERG) for a label-switched path (LSP) determined by the PCE usingsynchronization status information for a plurality of routing nodes inthe label-switched network; sending an MPLS echo request to a pluralityof downstream routing nodes specified by the SR ERG; receiving arespective MPLS echo reply from each of the downstream routing nodes;and validating the LSP using the MPLS echo replies using sent andreceived timestamps and, in response to validating the LSP,transitioning the LSP state from down to up; wherein sending an MPLSecho request to the downstream routing nodes comprises sending the MPLSecho request with a target forwarding equivalence class (FEC) stacktype-length-value (TLV) for validating the LSP.
 4. The method of claim3, comprising informing a test traffic generator to inject test packetsinto the LSP in response to validating the LSP.
 5. A non-transitorycomputer readable medium storing executable instructions that whenexecuted by at least one processor of a computer control the computer toperform operations comprising: at a multiprotocol label switching (MPLS)operations, administration, and maintenance (GAM) emulator, implementedon the at least one processor, and configured for emulating an MPLSelement in a label-switched network: receiving, from a path computationelement (PCE) for the label-switching network, a segment routing (SR)explicit route object (ERG) for a label-switched path (LSP) determinedby the PCE using synchronization status information for a plurality ofrouting nodes in the label-switched network; sending an MPLS echorequest to a plurality of downstream routing nodes specified by the SRERG; receiving a respective MPLS echo reply from each of the downstreamrouting nodes; and validating the LSP using the MPLS echo replies usingsent and received timestamps and, in response to validating the LSP,transitioning the LSP state from down to up; wherein sending an MPLSecho request to the downstream routing nodes comprises sending the MPLSecho request with a target forwarding equivalence class (FEC) stacktype-length-value (TLV) for validating the LSP.
 6. The non-transitorycomputer readable medium of claim 5, comprising informing a test trafficgenerator to inject test packets into the LSP in response to validatingthe LSP.